cuda.bindings: support multiple CTK release lines on main - #2737

This implies that (a) you are running from the root of the repo, and (b) you already did a pip install -r ci/tools/requirements.txt.

requirements.txt has been deprecated for a long time. We should either: add a pyproject.toml for ci/tools and require that the package is installed into a venv (which removes the $PWD problem), or use PEP 723 comments in each script and not have a proper package altogether.

Personally, I think PEP 723 is the simpler solution (it doesn't require juggling virtual environments), but it does require having uv or pixi around to run the script.

The argument in favor of a package would be if these scripts start to share a lot of logic and helpers between them such that things in ci/tools need to import other things in ci/tools. It doesn't look like they do right now, but in the original mega-PR they started to do that a bit.

Agreed. I chose the package option after the later refactor made the helpers genuinely share logic: bindings_scm_version, check_pixi_cuda_version, check_release_notes, and compute_ci_plan now import the registry/version machinery rather than duplicating it. The PR now adds ci/pyproject.toml, removes both requirements files, and installs ./ci in editable mode at workflow call sites. The documented module invocation therefore works through an installed package and no longer relies on $PWD putting the repository on Python's import path; PEP 723 would repeat the same dependency metadata across several scripts.

What's the purpose of this flag? It looks like it just spits the JSON provided right back out, doing nothing to it?

Agreed--it had no useful standalone meaning. --package-json and --github-env are gone. The only JSON-consuming operation is now the purpose-specific write-github-env GITHUB_ENV subcommand, which reads a selected package record from stdin, validates it, and appends only the supported environment variables. This removes the round-trip behavior and prevents that operation from being accidentally combined with registry-selection modes.

This duplication from versions.yml is worrisome, but I don't see any way around it. I think a precommit hook to make sure it's in sync with versions.yml would be a good idea.

Agreed. I added this check-bindings-config hook, triggered by ci/versions.yml or any bindings pyproject.toml. Registry validation reads each package root's tag_regex, constructs v<toolkit_version> from the registry, and requires the SCM regex to accept that exact version. Focused SCM tests additionally verify that the current 13.3 pattern rejects 13.4 and that metapackage SCM metadata matches both bindings roots. A normal release-family update on either side now fails locally and in CI if the duplicated metadata drifts.

Codex review — High: this gate consumes the aggregate TEST_BINDINGS / TEST_CORE / TEST_PYTHON flags for every CUDA-major matrix row. For a mixed change such as a v12 bindings file plus a cuda_core test, the plan builds only the v12 bindings test artifact but schedules core tests for both v12 and v13; the v13 row then reaches this step and requests a v13 artifact that was never built. The Windows workflow has the same shape. Please derive these gates per selected bindings line (or otherwise ensure each local row only downloads an artifact its root built) and add a mixed-change regression test.

Codex review — High: this verifies only that each distribution name appeared. I reproduced a successful v12 validation with a directory containing just one correctly named wheel, even though a release should contain every supported Python/platform/ABI variant. That can allow a partial TestPyPI/PyPI release after an artifact is missing, deleted, or expired. Please validate the complete expected wheel matrix (or exact expected artifact set from the build plan) before upload and add a partial-matrix rejection test.

Codex review — Medium: cuda-core-v* releases reach this fallback because release.yml does not pass bindings-package for cuda-core and the branch above recognizes only bare v* tags. This selects current control-plane bindings metadata instead of the metadata in the release tag. A delayed or historical core release can therefore request a newer bindings artifact that its tagged CI run never built (for example, cuda-core v1.0.0 used CUDA 13.2.1 while current control uses 13.3.0). Please resolve the bindings dependency from the checked-out release tag registry for component-prefixed releases too.

Codex review — Medium: real v12.9.1–v12.9.7 and v13.0.x tags store this metadata in ci/versions.json, not ci/versions.yml. Treating the YAML as absent sends those tags to the legacy fallback, which derives the line from today's control config; that only works while today's pins happen to match. Please probe and parse both legacy filenames from the tag tree before using control metadata, with a fixture shaped like an actual old tag.

Codex review — Medium: accepting .devN here makes a development tag valid for tag CI, but cuda_bindings/docs/build_docs.sh truncates the version to the first three dot components. As a result, v13.3.0.dev1 deploys production docs under 13.3.0, potentially occupying or overwriting the stable path even though release-wheel validation rejects development releases. Please retain the dev suffix in the docs path or prevent production docs deployment for dev tags.

Codex review — Medium: this is the CUDA 12 maintenance documentation, but the unpinned metapackage command now resolves the current v13 line. The [all] and Conda examples have the same issue, and the copied README/DESCRIPTION links target /cuda-bindings/latest/ (v13). Please pin the maintenance line (for example, cuda-python~=12.9.0 or cuda-bindings~=12.9.0) and direct readers to the versioned 12.9 docs or version selector.

Codex review — Medium: this copied v12 test omits the fixes already present in the current-root test for Orin/Thor and CUDA_VISIBLE_DEVICES. On a multi-GPU host with CUDA_VISIBLE_DEVICES=0, CUDA reports one visible GPU while NVML reports all GPUs, so this exact equality fails. Please port the current-root handling to the v12 copy, consistent with the cross-root handwritten-fix policy in cuda_bindings_12/MAINTENANCE.md.

Codex review — Low: this temporary repository disables commit signing but still inherits global tag signing. With tag.gpgSign=true, the plain git tag calls fail or prompt (I reproduced 14 failures); with tag signing disabled, the same suite passes. Please set tag.gpgSign=false here and in the analogous temp-repo helper in test_lookup_run_id.py, or create tags with --no-sign, so the tests are hermetic.

Codex review — Pre-merge cleanup: this temporary file is still tracked and suppresses link checks for paths that do not yet exist on main. Please remove it before the final CI run and merge, as its header and the PR checklist require.